Moving data between JavaScript and native is extremely slow, especially for binary which Cordova has to base64 encode and then transmit over XHR or as an URL parameter. The last thing we want to do is send more data. For some reason SQL statements and their parameters were being sent twice because they were duplicated to a `query` member. That member was only used by the iOS plugin, so this fix removes it and updates the iOS plugin to use the sql and params members like the others.

Additionally, the iOS plugin is updated to handle unsupported types during binding and a test was added to verify.

(@brodybits) from pull #170, adding www/SQLitePlugin.js updated from SQLitePlugin.coffee.md

The plugin id used here must match the one in plugin.xml or the test runner will fail to remove it when deployed.

(@brodybits) from pull request #170 thanks @aarononeal

The test was closing the database in the middle of an execute transaction. This would cause the transaction to fail because at the exit of the transaction handler a commit would be issued on a closed database. This fix moves the close to the success handler of the transaction so that the final close occurs after the transaction ends.

Additionally, the db variable is now obtained from the open callback instead of the function result, which is a more consistent pattern for async.

Finally, the close method was updated to fail if an attempt is made to call it while a transaction is active and a test was added to confirm this behavior.

(@brodybits) from pull #170 thanks @aarononeal, adding www/SQLitePlugin.js as updated from SQLitePlugin.coffee.md

Important changes:
- Implement pre-population ref: #10/#172
- Choose DB location to make iCloud backup optional ref: #16/#143
- Fix db close conditions & prevent double-marshaling of data ref: pull #170

According to the W3C spec, if a transaction failure callback *does not return false* then the error is propagated to a transaction failure. This means that if a transaction returns true, but more importantly, if it has no return value (undefined) then the error must propagate to the transaction. This fix explicitly requires false to correct the propagation.

A subsequent fix will address the fact that the original statement error is not propagated and is replaced here, but that is unrelated to this issue.

(@brodybits) from PR #170 thanks @aarononeal, adding www/SQLitePlugin.js as updated from SQLitePlugin.coffee.md

Sometimes the native layer returns errors as {message:string, code:number} and other times as just a string. This fix wraps key places to ensure that errors returned through the API always conform to SQLError per the API contract documented in the W3C spec.

In short, errors consistently have a message and code now and propagate from statement failure up to the transaction.

(@brodybits) from PR #170 thanks @aarononeal, adding www/SQLitePlugin.js as updated from SQLitePlugin.coffee.md

) & other minor cleanups

See PR #170: similar to commit c19698b but with a different solution

Parameters use `,` not `;`.

(@brodybits) from PR #170 thanks @aarononeal

If executeSql is called on a finalized transaction it should throw. If it does not, timing errors get a lot harder to debug. ES6 promises, for example, generally execute on the next tick and then it becomes unclear why a statement fails to execute.

(@brodybits) from PR #170 thanks @aarononeal, adding www/SQLitePlugin.js as updated from SQLitePlugin.coffee.md

Strings with Unicode values like `\u0000` ARE being truncated because the string constructor was using a null terminator to determine size instead of the stored byte length.

(@brodybits) from PR #170 thanks @aarononeal. The fix will be committed separately.

This fix enables end-to-end encoding of binary data using strings.

Strings with Unicode values like `\u0000` were being truncated because the string constructor was using a null terminator to determine size instead of the stored byte length. The fix uses a different constructor and the stored byte length so that the full length string is returned.

(@brodybits) from PR #170 thanks @aarononeal. Test was already committed separately.

… for improvements to SQL blob storage]

(@brodybits) from PR #170 thanks @aarononeal.

NOTE: changes related to SQL blob binding are #ifdef'd out (TBD subjet to change).

…onditionally-included SQL binding code (ref: PR #170)

Small fix to handling of Blob to prepare for SQL blob improvements (ref: PR #170)

Fixes:
- #193: workaround for Android db locking/closing issue
- #144: convert array parameters to string to match Web SQL
- #199: fix double-precision REAL values in result for iOS version
- #150/#153: close Android db before removing from map
- Fix truncation in iOS query result in case of UNICODE NULL (\0 or \u0000) (ref: PR #170)
- Some fixes for error handling to be consistent with Web SQL (ref: PR #170)

Testing ONLY:
- #147: testing with UNICODE line separator
- #195: Reproduce issue with double-precision REAL number on WP(8) ONLY

Fixes:
- #193: workaround for Android db locking/closing issue
- #144: convert array parameters to string to match Web SQL
- #199: fix double-precision REAL values in result for iOS version
- #150/#153: close Android db before removing from map
- Fix truncation in iOS query result in case of UNICODE NULL (\0 or \u0000) (ref: PR #170)
- Some fixes for error handling to be consistent with Web SQL (ref: PR #170)

Testing ONLY:
- #147: testing with UNICODE line separator
- #195: Reproduce issue with double-precision REAL number on WP(8) ONLY

Related to the following fixes:
- #193: workaround for Android db locking/closing issue
- #144: convert array parameters to string to match Web SQL
- #199: fix double-precision REAL values in result for iOS version
- #150/#153: close Android db before removing from map
- Fix truncation in iOS query result in case of UNICODE NULL (\0 or \u0000) (ref: PR #170)
- Some fixes for error handling to be consistent with Web SQL (ref: PR #170)

…OS version (ref: PR #170)